Unsolicited communication such as SPAM is becoming an increasing problem on the Internet. While there may be many types of unwanted traffic, SPAM is usually defined to be communication which is not only unwanted, but also mass distributed. Often, this mass distribution is accomplished by automated (machine based) generation of the messages. There is a fear that SPAM will spread to telecommunication operator networks, such as fixed or mobile telecommunication operator network. Such SPAM in a telecommunication network is not only annoying to the user or party receiving it. It may also lead to network waste and possibly incorrect or seemingly unfair charging of end-users. There is also a fear that SPAM will spread to non-email services such as IP Telephony (SPAM over IP Telephony, “SpIT”), Instant Messaging (SPAM over Instant Messaging, “SpIM”), and in general to any/all IP Multimedia Subsystems (IMS) service based services.
In the case that the IMS is provided by a 3rd Generation Partnership Project (3GPP) operator, it could be argued that users will be authenticated and the perpetrator (the source of the unsolicited communication) can be identified. Still, it does not prevent SPAM/SpIM/SpIT. Also, there is need to support the case when only one (or neither) of the parties use 3GPP hosted services.
Because of this there is a need to be able to at least broadly authorize a communication initiator in a communication network in order to be able to take counter-measures for preferably stopping undesirable communication to take place. It is in this respect of interest for a party at the receiving end to have this done without being involved. However, this party at the receiving end naturally does not want to have all such communication initiating parties to be barred.
Various techniques to mitigate SPAM have been proposed. A common denominator is that the techniques are based on “challenging” the sender/initiator of the communication. The idea is either to impose a computational load on the sender's computing device by asking the sender to solve a computational puzzle thereby limiting the rate at which the sender can initiate communication, or, to give the sender a task which only a human user would be able to solve, thereby using the fact that humans have limited computing power. This will slow down the process of sending SPAM or make it expensive, since it would need the involvement of humans. The latter form of challenges can thus be seen as a form of “Turing test”, in this context known as “Completely Automated Public Turing-test to tell Computers and Humans Apart” (CAPTCHA). A typical such CAPTCHA may consist of asking the user to describe a picture or video, or to summarize some “semantical” meaning of a spoken sentence. A CAPTCHA can also be the sending of an image with “warped” or twisted characters, like numbers or letters that cannot easily be identified by a machine, for instance using character recognition such as Optical Character Recognition (OCR), while being easily identifiable by a human.
A problem with computational puzzles is that it is difficult to issue a puzzle that is “suitably” hard, as it is of interest to let a legitimate sender to be able to send even if he has a “thin” device, while at the same time it is desirable to prevent malicious “spammers” from sending bulk email, even if they have a large computer cluster to assist.
CAPTCHAs have, as was mentioned earlier, been used frequently in relation to the Internet. Examples on this are given in WO 2008/030363. Here a CAPTCHA is combined with contextual background, such as data relating to an on-line application environment provided by a provider, such as an on-line payment environment. This means that a user who wants to access a service provided by a provider is presented with a CAPTCHA that has been combined with contextual data of the service provider and normally of the service itself.
CAPTCHAS in relation to various terminals including mobile telephones has also been proposed in US 2009/0083826.
There is however still a problem in how to select a good challenge, like a CAPTCHA. First of all, since it is desirable to avoid unnecessary disturbance of the party at the receiving end of the communication, all situations where the challenge is actively chosen by the receiving party are unsuitable. Furthermore, if the communication initiator is visually or hearing impaired he or she may not be able to solve a visual or audio challenge CAPTCHA. Even if a challenge that could be understood by the communication initiator is used, this communication initiator could be in a situation where the challenge is unsuitable at a given point in time. For example, if the communication initiator is “mobile”, such as driving a car, it could be dangerous to distract him or her by forcing him or her to look at the screen of a terminal on which the challenge is presented. Some terminals may furthermore lack displays and then it is also impossible to view a visual challenge. In summary, there is a need for an improved way to select challenges.